Skip to content

generate libtool which groks llvm openmp on macOS, detect it#49

Open
dimpase wants to merge 4 commits into
malb:masterfrom
dimpase:macosOopenMPfix
Open

generate libtool which groks llvm openmp on macOS, detect it#49
dimpase wants to merge 4 commits into
malb:masterfrom
dimpase:macosOopenMPfix

Conversation

@dimpase

@dimpase dimpase commented May 21, 2026

Copy link
Copy Markdown
Contributor 
the biggish changes are

 1) m4/m4_ax_openmp.m4 - which is replacing ax_openmp.m4 with a patched mainline (autoconf 2.72)
AC_OPENMP - still named AX_OPENMP - to understand "-Xpreprocessor -fopenmp" Apple clang flags.
The advantage is that it's just better in the way of support
and cleanup of the mess left from testing flags.

 2) build-aux/ltmain.sh.in - modified libtool sources to include the upstream commit
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?id=c9c59804175920990ae2dc9706fa23a2cd4717b0

The rest is small and needed to explicitly pass -lomp flag to the linker (this
is llvm's libomp, not to be confused with incompatible GNU libgomp) and generate libtool from the
included source.

On Homebrew this can be tested by

  brew install libomp
  export CPATH=`brew --prefix`/opt/libomp/include
  export LIBRARY_PATH=`brew --prefix`/opt/libomp/lib
  ./configure --enable-openmp
  [etc]

dimpase added 3 commits May 21, 2026 07:26
@dimpase
generate libtool which groks llvm openmp on macOS, detect it
e242f0f 
the biggish changes are

 1) m4/m4_ax_openmp.m4 - which is replacing ax_openmp.m4 with a patched mainline (autoconf 2.72)
AC_OPENMP - still named AX_OPENMP - to understand "-Xpreprocessor -fopenmp" Apple clang flags.
The advantage is that it's just better in the way of support
and cleanup of the mess left from testing flags.

 2) build-aux/ltmain.sh.in - modified libtool sources to include the upstream commit
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?id=c9c59804175920990ae2dc9706fa23a2cd4717b0

The rest is small and needed to explicitly pass -lomp flag to the linker (this
is llvm's libomp, not to be confused with incompatible GNU libgomp) and generate libtool from the
included source.

On Homebrew this can be tested by

  brew install libomp
  export CPATH=`brew --prefix`/opt/libomp/include
  export LIBRARY_PATH=`brew --prefix`/opt/libomp/lib
  ./configure --enable-openmp
  [etc]
@dimpase
put openmp flags into m4ri.pc
916ecbf
@dimpase
test with OpenMP on macOS
552ac5d
@dimpase dimpase force-pushed the macosOopenMPfix branch from 7653461 to c774f84 Compare May 21, 2026 15:18
@dimpase

dimpase commented May 21, 2026

Copy link
Copy Markdown
Contributor Author

there are a couple of issues here.

  • as we build libtool while running ./configure, various libtool-related things are installed from what's on the system. If the versions match, we are OK. If the system libtool is older, it complains and errors out
libtool: Version mismatch error.  This is libtool 2.5.4, but the
libtool: definition of this LT_INIT comes from libtool 2.4.7.
libtool: You should recreate aclocal.m4 with macros from libtool 2.5.4
libtool: and run autoconf again.

I don't know how to fix this easily. I guess a full-blown installation of libtool from source prior to building m4ri would do, but that's a bit of work for not too much gain. I'll see if this is feasible on the CI.

  • on Homebrew macOS, libomp is installed in a non-standard location. One either has to keep setting CPATH and LIBRARY_PATH to point to it, or to add options to ./configure to point at them, then these will be used.

@dimpase dimpase force-pushed the macosOopenMPfix branch from c7e2796 to d7bae5f Compare May 21, 2026 17:22
@dimpase

dimpase commented May 21, 2026

Copy link
Copy Markdown
Contributor Author

OK, the CI works now. It's a big ugly, but, well...

malb
malb reviewed May 21, 2026
View reviewed changes
Comment thread .github/workflows/distcheck.yml
sudo DEBIAN_FRONTEND=noninteractive apt-get install autoconf automake libtool
sudo DEBIAN_FRONTEND=noninteractive apt-get install autoconf automake
cd /tmp
wget https://ftpmirror.gnu.org/libtool/libtool-2.5.4.tar.gz

@malb malb May 21, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this at all, this is asking for trouble. We shouldn't force a new libtool on Linux testing for OSX.

@dimpase dimpase May 21, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should not be held hostage by GitHub not updating their runners :-)

@dimpase

dimpase commented May 21, 2026

Copy link
Copy Markdown
Contributor Author

Well, libtool 2.5.4 has been released in Nov 2024. It's of course not new that Debian/Ubuntu is asleep at the wheel, along with GNU in general.

Other major build systems such as cmake and meson support this sort of flags without any problems. And for a good reason - they are crucial to build code which loads tasks on GPUs.!

@dimpase

dimpase commented May 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

besides, it does not matter for configured tarballs, one can make dist on a system with up to date libtool, and m4ri from the configured tarball then can be installed on another system without a libtool, or with a different libtool.

@malb

malb commented May 21, 2026

Copy link
Copy Markdown
Owner

I sympathise but I can't commit to maintaining code where the CI runs some hardcoded libtool version. Sorry.

@dimpase

dimpase commented May 21, 2026

Copy link
Copy Markdown
Contributor Author

I can propose the following hack - detect the system libtool version in configure, and use it to fill the template in build-aux/ltmain.sh.in.
It will alleviate the need to use a matching version of libtool.

Would you accept this?

@malb

malb commented May 26, 2026

Copy link
Copy Markdown
Owner

I'm not actively ignoring this, just got a bunch on.

@dimpase

dimpase commented May 27, 2026

Copy link
Copy Markdown
Contributor Author

in case, libtool 2.6.1, with the needed fix, will be out in a month or two. Hopefully it can make it into Homebrew at some point.

Meanwhile, m4ri is a formula in Homebrew (not using OpenMP, they don't like patches to upstream packages).
https://formulae.brew.sh/formula/m4ri#default

I'll submit m4rie to Homebrew this week.

@malb

malb commented Jun 10, 2026

Copy link
Copy Markdown
Owner

How does libtool 2.6.1 change this PR? Would it become redundant or would it need to be changed?

@dimpase

dimpase commented Jun 10, 2026

Copy link
Copy Markdown
Contributor Author

with libtool 2.6.1, what's left here would be start using OpenMP in CI: ./configure --enable-openmp etc.,
but no libtool hacks needed any more

@malb

malb commented Jun 10, 2026

Copy link
Copy Markdown
Owner

okay cool, let's wait :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@malb malb malb left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@dimpase @malb